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DETAILED ACTION 

1 . In view of the Appeal Brief filed on 08 April 2008, PROSECUTION IS HEREBY 
REOPENED. New grounds of rejection are set forth below. 

To avoid abandonment of the application, appellant must exercise one of the 
following two options: 

(1 ) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply 
under 37 CFR 1 .1 1 3 (if this Office action is final); or, 

(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41 .31 followed 
by an appeal brief under 37 CFR 41 .37. The previously paid notice of appeal fee and 
appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth 
in 37 CFR 41 .20 have been increased since they were previously paid, then appellant 
must pay the difference between the increased fees and the amount previously paid. 

A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by 
signing below: 

2. Claims 1 , 2, 4-8, 11,12, 14-22 and 24 remain pending. 

Claim Rejections - 35 USC §112 
The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

3. Claims 11,12 and 14-17 rejected under 35 U.S.C. 112, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject matter 
which applicant regards as the invention. 
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4. Claim 1 1 recites the limitation "the generic output" in line 6. There is insufficient 
antecedent basis for this limitation in the claim. For examination purposes, the claim will 
be interpreted so that "the generic output" refers to the "one or more generic health 
metrics" in lines 5-6 of the claim. Appropriate correction is required. 

5. Claims 1 2 and 14-17 are rejected based on their dependency on claim 1 1 . 

Claim Rejections - 35 USC § 103 

6. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

7. This application currently names joint inventors. In considering patentability of 
the claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of 
the various claims was commonly owned at the time any inventions covered therein 
were made absent any evidence to the contrary. Applicant is advised of the obligation 
under 37 CFR 1 .56 to point out the inventor and invention dates of each claim that was 
not commonly owned at the time a later invention was made in order for the examiner to 
consider the applicability of 35 U.S.C. 1 03(c) and potential 35 U.S.C. 1 02(e), (f) or (g) 
prior art under 35 U.S.C. 103(a). 

8. Claims 1, 2, 4, 5, 6, 8, 11, 12, 14, 17-22 and 24 are rejected under 35 U.S.C. 
103(a) as being unpatentable over "Systems Management: Application Response 
Measurement (ARM) API" (The Open Group), hereinafter referred to as "ARM API", in 
view of Leymann et al. (US 6,633,908 B1), hereinafter referred to as Leymann. 
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9. Regarding claim 1 , ARM API teaches a method for dynamically determining the 
health of a service resident on a host machine (page 3, figure 1-1), comprising: 

collecting service performance information (p. 3, fig. 1-1, measurement agent) 
from the resident service (p. 3, fig. 1-1 , client, server end systems), wherein the 
collected service information relates to a plurality of performance metrics (fig. 1-1 , 
monitor application response); and 

wherein the output comprises a plurality of service health metrics, and the 
plurality of performance metrics to provide one or more of the plurality of service health 
metrics, wherein the plurality of service health metrics comprises availability, capacity, 
throughput, service time, queue length, utilization, service level violations, and user 
satisfaction (fig. 1-1, monitor application response). 

ARM API teaches in (fig. 1-1, monitor application response) the collection of 
service performance information by an ARM API wherein the output is one of a 
scriptable interface and application programming interface (fig. 1-1, use of ARM API) 
and useable by different performance monitoring tools (fig. 1-1, measurement agent) 
but does not explicitly recite the translation of the performance information into a 
generic output. However, in related art, Leymann teaches these features. Leymann 
teaches the utilization of an application response measurement API (fig. 1, 106) in 
communication with an API sub-agent (fig. 1 , 107) over a network wherein an agent is 
utilized for data handling and is deemed generic in order to be independent from a 
specific application and therefore the data is available for all applications requesting the 
data (col. 8, II. 3-14). In view of Leymann, it is therefore deemed that it would have been 
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obvious to one of ordinary skill in the art to implement the ARM API to translate the 
collected service performance information in to a generic output. One of ordinary skill in 
the art would have been motivated to incorporate the teachings of Leymann with ARM 
API in order to implement independence from a specific application and make the data 
available for a wide range of calling applications (Leymann, col. 8, II. 9-1 3). 

10. Regarding claim 2, ARM API and Leymann teach the method wherein the host 
machine comprises one or more components, further comprising: 

collecting external performance information from one or more of the one or more 
components (ARM API, fig. 1-1, monitor application response); 

translating the collected external performance information (Leymann, col. 8, II. 9- 
13); and 

combining the translated external performance information and the translated 
service performance information to provide the generic output (Leymann, col. 8, II. 9- 
13). 

1 1 . Regarding claim 4, ARM API and Leymann teach the method further comprising 
accessing the generic output to read the health of the service (Leymann, col. 8, II. 9-13). 

12. Regarding claim 5, ARM API and Leymann teach the method wherein the 
collecting step comprises reading performance information provided by the service 
(ARM API, fig. 1-1, monitor application response). 

13. Regarding claim 6, ARM API and Leymann teach the method wherein the 
collecting step comprises deriving performance information from the service (ARM API, 
fig. 1-1, monitor application response). 
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14. Regarding claim 8, ARM API and Leymann teach the method wherein the 
deriving step comprises using a probe program to read the performance information 
(Leymann, col. 8, II. 9-13, data read by independent components). 

1 5. Regarding claim 1 1 , ARM API teaches an apparatus that determines a health of 
a service resident on a host machine, comprising: 

a data collection engine (p. 3, fig. 1-1, measurement agent) that collects service 
health information (fig. 1-1, monitor application response); 

wherein the collected service health information relates to a plurality of 
performance metrics, the plurality of performance metrics to provide one or more of the 
plurality of service health metrics, wherein the plurality of service health metrics 
comprises availability, capacity, throughput, service time, queue length, utilization, 
service level violations, and user satisfaction (fig. 1-1, monitor application response). 

ARM API teaches in (fig. 1-1, monitor application response) the collection of 
service performance information by an ARM API wherein the output is one of a 
scriptable interface and application programming interface (fig. 1-1, use of ARM API) 
and useable by different performance monitoring tools (fig. 1-1, measurement agent) 
but does not explicitly recite the translation of the data in a health generation algorithm 
providing one or more generic health metrics. However, in related art, Leymann 
teaches these features. Leymann teaches the utilization of an application response 
measurement API (fig. 1, 106) in communication with an API sub-agent (fig. 1, 107) 
over a network wherein an agent is utilized for data handling and is deemed generic in 
order to be independent from a specific application and therefore the data is available 
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for all applications requesting the data (col. 8, II. 3-14). In view of Leymann, it is 
therefore deemed that it would have been obvious to one of ordinary skill in the art to 
implement the ARM API to translate the collected service performance information in to 
a generic output. One of ordinary skill in the art would have been motivated to 
incorporate the teachings of Leymann with ARM API in order to implement 
independence from a specific application and make the data available for a wide range 
of calling applications (Leymann, col. 8, II. 9-13). 

16. Regarding claim 12, ARM API and Leymann teach the apparatus wherein the 
host machine comprises one or more external components, wherein the data collection 
engine collects external performance information from one or more external 
components (ARM API, fig. 1-1, monitor application response) and wherein the data 
analysis engine translates the collected external information using the health generation 
algorithm to provide the one or more generic health metrics (Leymann, col. 8, II. 3-14). 

17. Regarding claim 14, ARM API and Leymann teach the apparatus wherein the 
data collection engine, comprises: 

a data query module that reads performance information from the service (ARM 
API, fig. 1-1, measurement agent); and 

a data derivation module that derives performance information from the service 
(ARM API, fig. 1-1, monitor application response). 

18. Regarding claim 17, ARM API and Leymann teach the apparatus further 
comprising an interval control engine that receives the service health information at a 
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first time interval and provides an output having a second time interval different from the 
first time interval (Leymann, col. 8, II. 3-7). 

19. Regarding claim 18, ARM API teaches an apparatus that determines a health of 
a service resident on a host machine, comprising: 

a data collection engine (p. 3, fig. 1-1, measurement agent) that collects service 
health information (fig. 1-1, monitor application response); 

wherein the collected service health information relates to a plurality of 
performance metrics, the plurality of performance metrics to provide one or more of the 
plurality of service health metrics, wherein the plurality of service health metrics 
comprises availability, capacity, throughput, service time, queue length, utilization, 
service level violations, and user satisfaction (fig. 1-1, monitor application response). 

ARM API teaches in (fig. 1-1, monitor application response) the collection of 
service performance information by an ARM API wherein the output is one of a 
scriptable interface and application programming interface (fig. 1-1, use of ARM API) 
and useable by different performance monitoring tools (fig. 1-1, measurement agent) 
but does not explicitly recite the translation of the data in a health generation algorithm 
providing one or more generic health metrics. However, in related art, Leymann 
teaches these features. Leymann teaches the utilization of an application response 
measurement API (fig. 1, 106) in communication with an API sub-agent (fig. 1, 107) 
over a network wherein an agent is utilized for data handling and is deemed generic in 
order to be independent from a specific application and therefore the data is available 
for all applications requesting the data (col. 8, II. 3-14). In view of Leymann, it is 
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therefore deemed that it would have been obvious to one of ordinary skill in the art to 
implement the ARM API to translate the collected service performance information in to 
a generic output. One of ordinary skill in the art would have been motivated to 
incorporate the teachings of Leymann with ARM API in order to implement 
independence from a specific application and make the data available for a wide range 
of calling applications (Leymann, col. 8, II. 9-13). 

20. Regarding claim 19, ARM API and Leymann teach the method wherein the step 
of collecting the service performance information comprises reading first service 
performance parameters, and wherein the step of collecting the external performance 
information comprises reading first external performance parameters and deriving 
second external performance parameters (ARM API, fig. 1-1, monitor application 
response). 

21 . Regarding claim 20, ARM API and Leymann teach the method further comprising 
collecting the service performance information on a first time interval and adjusting the 
first time interval to provide the generic service health output at a second time interval 
(Leymann, col. 8, II. 3-7). 

22. Regarding claim 21 , ARM API teaches an apparatus that determines a health of 
a service, wherein the service operates on a host computer (page 3, figure 1-1), 
comprising: 

a collection module that receives performance information related to the service 
(p. 3, fig. 1-1, measurement agent); and 
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wherein the output comprises a plurality of service health metrics, and the 
plurality of performance metrics to provide one or more of the plurality of service health 
metrics, wherein the plurality of service health metrics comprises availability, capacity, 
throughput, service time, queue length, utilization, service level violations, and user 
satisfaction (fig. 1-1, monitor application response). 

ARM API teaches in (fig. 1-1, monitor application response) the collection of 
service performance information by an ARM API wherein the output is one of a 
scriptable interface and application programming interface (fig. 1-1, use of ARM API) 
and useable by different performance monitoring tools (fig. 1-1, measurement agent) 
but does not explicitly recite the translation of the performance information into a 
generic output. However, in related art, Leymann teaches these features. Leymann 
teaches the utilization of an application response measurement API (fig. 1, 106) in 
communication with an API sub-agent (fig. 1 , 1 07) over a network wherein an agent is 
utilized for data handling and is deemed generic in order to be independent from a 
specific application and therefore the data is available for all applications requesting the 
data (col. 8, II. 3-14). In view of Leymann, it is therefore deemed that it would have been 
obvious to one of ordinary skill in the art to implement the ARM API to translate the 
collected service performance information in to a generic output. One of ordinary skill in 
the art would have been motivated to incorporate the teachings of Leymann with ARM 
API in order to implement independence from a specific application and make the data 
available for a wide range of calling applications (Leymann, col. 8, II. 9-1 3). 
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23. Regarding claim 22, ARM API and Leymann teach the apparatus wherein the 
collection module receives external performance information from one or more external 
services coupled to the host computer and receives internal performance information 
related to operation of the service on the host computer (ARM API, fig. 1-1, monitor 
application response). 

24. Regarding claim 24, ARM API and Leymann teach the apparatus wherein the 
generic health metrics is one of a scriptable interface and an application programming 
interface (ARM API, use of API for response measurement). 

25. Claims 7 and 15 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
ARM API and Leymann in view of Chappelle (US 5,949,976). 

26. Regarding claim 7, ARM API and Leymann do not explicitly teach of using a 
wrapper program. Chappelle teaches about using a wrapper program (performance 
monitoring and graphing tool) to read the performance information (col. 3, II. 29-32). 
The examiner is interpreting wrapper program as any program that is used as an 
interface program because this gives the broadest reasonable interpretation. In ARM 
API's specification, the performance forecasting system communicates with one or 
more monitoring system (fig. 1-1 , enterprise management solutions). It would have 
been obvious to one of ordinary skill in the art at the time of the applicant's invention to 
utilize the teaching of Chappelle in regards to using a wrapper program because it 
would have allowed the performance forecasting system to read the information 
supplied by various monitoring systems regardless of the components particular 
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infrastructure. One of ordinary skill in the art would have been motivated because this 
modification would result in a more versatile system as outlined above. 

27. Regarding claim 15, ARM API and Leymann do not explicitly teach of using a 
wrapper program. Chappelle teaches about using a wrapper program (performance 
monitoring and graphing tool) to read the performance information (col. 3, II. 29-32). 
The examiner is interpreting wrapper program as any program that is used as an 
interface program because this gives the broadest reasonable interpretation. In ARM 
API's specification, the performance forecasting system communicates with one or 
more monitoring system (fig. 1-1 , enterprise management solutions). It would have 
been obvious to one of ordinary skill in the art at the time of the applicant's invention to 
utilize the teaching of Chappelle in regards to using a wrapper program because it 
would have allowed the performance forecasting system to read the information 
supplied by various monitoring systems regardless of the components particular 
infrastructure. One of ordinary skill in the art would have been motivated because this 
modification would result in a more versatile system as outlined above. 

28. Claim 16 is rejected under 35 U.S.C. 103(a) as being unpatentable over ARM 
API and Leymann in view of Walrand et al. (US 6,647,413), hereinafter referred to as 
Warland. 

29. Regarding claim 1 6, ARM API and Leymann do not explicitly teach of a weighting 
scheme that weights one or more performance information parameters; a summation 
scheme that combines one or more performance information parameters; and a 
averaging scheme that averages collected service health information for a service 
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health metric. However, Walrand teaches on these aspects. Walrand teaches about a 
summation scheme that combines one or more performance information parameters 
(col. 7, II. 32-33) and an averaging scheme that averages collected service health 
information for a service health metric (col. 7, II. 55-57). In HPCN Walrand teaches of a 
weighting scheme that allocates different level of importance to different parameters (p. 
2). One objective of Walrand invention is to optimize the network performance (col. 2, II. 
53-54). It would have been obvious to one of ordinary skill in the art at the time of the 
applicant's invention to utilize the above mentioned features of Walrand's into ARM API 
and Leymann because adding these features to ARM API and Leymann would allow 
focus on specific parameters (using the weighting scheme) and give information 
regarding the overall performance of the network system (using the summation and 
averaging schemes). These added features would allow ARM API and Leymann to 
provide a healthy network and more effectively predict failure of registered computing 
devices (col. 2, II. 25-34) resulting in a more efficient performance forecasting system. It 
is for this reason that one of ordinary skill in the art at the time of invention would have 
been motivated to make the above-mentioned modifications. 

Response to Arguments 
30. Applicant's arguments, see Appeal Brief (pp. 10-13), filed 08 April 2008, with 
respect to the rejection(s) of claim(s) claims 1 , 2, 4-6, 8,11,12,14,15,1 7-22 and 24 
under 35 U.S.C. 103(a) as being unpatentable over Helsper et al. (US 6,876,988 B2), 
Scarpelli et al. (US 6,816,898 B1) and Goodman et al. (US 7,020,697 B1) have been 
fully considered and are persuasive. Therefore, the rejection has been withdrawn. 
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However, upon further consideration, a new ground(s) of rejection is made in view of 
ARM API and Leymann as set forth above. 
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Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Benjamin Ailes whose telephone number is (571)272- 
3899. The examiner can normally be reached Monday-Friday, 5:30-8:30AM, 1 :00- 
6:00PM, IFP Hoteling schedule. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Andrew Caldwell can be reached on 571-272-3868. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

BAA 

/Andrew Caldwell/ 

Supervisory Patent Examiner, Art Unit 2142 



